Compile the tree on a pull request, with warnings as errors (#15) - #183

The issue this belongs to

Closes #15

It also carries the third done-condition of #13, which is that the gate workflows
added in this milestone invoke the same two commands README.md gives a
contributor rather than variants of them. This is the first such workflow. #13 is
named rather than closed here and closes on its own once this lands.

What changed

One workflow file. Its check-run name is exactly build, on both the workflow
and the job, and it runs cargo build --locked --all-targets with every warning
an error, on every pull request against every branch and on every push to main.

The means, and why it fits

A workflow file, because the thing being added is a check GitHub runs and there
is no other way to declare one. The logic inside it is a single command from
README.md rather than a shell block, so there is nothing here that owes a
fixture of its own; where this board puts logic in shell it puts it in a script
with its own fixtures, and this change deliberately has none to put there.

What failure it prevents

Nothing compiled this repository on a pull request. The checks here read
documents, workflows, shell and the dependency graph, and none of them asked
whether the code builds at all. A tree that does not compile could land.

The second one is narrower and is the reason the job carries no if: and no path
filter. GitHub creates a check run for a job it started and then skipped, and it
carries the job's name exactly as a job that did the work would, so the cheapest
thing satisfying "the name appears in that list" is a workflow that compiles
nothing. The comment on #15 measured that shape on a live repository before this
was written.

Evidence

The check-run names on the default branch before this, which is the state #15
describes:

gh api repos/Flowfin/core/commits/main/check-runs --jq '.check_runs[].name'
Reject Trojan Source Unicode
Scorecard analysis
Analyse the shell the gate runs (shellcheck)
Audit workflows (zizmor)

There is no build among them. That listing has grown by one since the comment on
#15 quoted it, and the addition is the shell analysis rather than anything that
compiles.

What a guard here refuses, and the proof it bites

It refuses a compiler warning, and the direction was proven twice: once on this
machine before the workflow was written, and once on the runner, because a
direction proven on one machine is not the direction the gate has.

On this machine, an unused import and the exact command the workflow runs:

RUSTFLAGS="-D warnings" cargo build --locked --all-targets
error: unused import: `std::collections::HashMap`
  --> src\lib.rs:51:5
   |
51 | use std::collections::HashMap;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: `-D unused-imports` implied by `-D warnings`
error: could not compile `flowfin-core` (lib) due to 1 previous error

and green again with the import removed:

RUSTFLAGS="-D warnings" cargo build --locked --all-targets
   Compiling flowfin-core v0.0.0
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 8.06s

On the runner, the same import pushed to this branch as its own commit, with the
commit after it taking it out again. The two proof commits cancel, so what this
pull request changes against main is the workflow file alone:

git diff --stat origin/main HEAD
 .github/workflows/build.yml | 72 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

The green run before the warning, run 32811357035, which is also the evidence that
the job compiles rather than being a name in a list:

rustc 1.97.1 (8bab26f4f 2026-07-14)
cargo 1.97.1 (c980f4866 2026-06-30)
   Compiling flowfin-core v0.0.0 (/home/runner/work/core/core)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 11.76s

The red run with the warning in it, run 32811533858:

  RUSTFLAGS: -D warnings
error: unused import: `std::collections::HashMap`
   = note: `-D unused-imports` implied by `-D warnings`
error: could not compile `flowfin-core` (lib) due to 1 previous error
error: could not compile `flowfin-core` (lib test) due to 1 previous error
##[error]Process completed with exit code 101.

and the run on the head of this branch, with the import taken out, is green again
in the check list on this pull request.

What this does not cover

Only the build. Whether the tests pass is #16 and is a different check name; a
green build says the tree compiles and says nothing about a test.

Only this runner and this operating system. Which target triples the gate covers
is #113, and nothing here cross-compiles.

The toolchain is the runner image's, because #14 has not pinned one. The job
prints rustc -vV and cargo --version on every run so that which compiler
produced a verdict is in the log, but the version can move under this check
without anything here noticing, and that is exactly what #14 is for.

The name is not required on main. #26 is what writes the required names into
the ruleset, and until it does, a red build blocks no merge:

gh api repos/Flowfin/core/rulesets/20572113 --jq '[.rules[].type]'
["deletion","non_fast_forward","pull_request"]

Who has read it

Nobody but me. There is no second reader on this board tonight, and the evidence
above stands in place of one.